OK wizards....got a " Security Fail" for the first time today. All
other indications A-OK. I tried downloading the flight again, still no
luck. I went back and downloaded an older flight and got a "Security
OK" note. Looking for ideas as I try to locate my manual.
Thanks
R

Romeo,

First of all, I can't answer to the call of "wizard." Folks on my
field call me by other "terms of endearment."

But that won't prevent me from pitching in and trying to answer. Your
issue is why I try to keep an appropriately-sized cardboard box
handy. So I can ship my 302 to Cambridge. I don't know what it is,
but I would suspect your 302 will need a check-up at Cambridge. I've
had the same problem before.

I've lost count, but my 302 has been back to Cambridge at least twice,
maybe three times in the four or so years (maybe longer?) that I've
had it. And, it's time to go back again. Now, the audio function of
the vario seems "off." And, it's time for a recalibration (I'm gonna
get 500 km this coming year, I just know it! ;-)

Ray Lovinggood
Carrboro, North Carolina, USA

And now, OLC won't accept my log from my CAI M-25 due to "format"
issues and request I email it to the help desk. Hmmmmm
I have since discover that the 302 memory battery may need replacing
by Cambridge and only Cambridge ( I have a special place for that
perfect 302 mailing box, I'm ahead of you girl).
Lets shift this topic over to M-25 format issues, any help on this
one?
(I need to turn on the AC, its hot down here)
R

On Dec 7, 2:58*pm, " > wrote:
> OK wizards....got a " Security Fail" for the first time today. All
> other indications A-OK. I tried downloading the flight again, still no
> luck. I went back and downloaded an older flight and got a "Security
> OK" note. Looking for ideas *as I try to locate my manual.
> Thanks
> R

Oh well you have not been periodically clearing the log memory on your
Cambridge 302 have you?

The flight trace you downloaded should contain all the flight
information, just it won't validate as a secure log. You are probably
SOL if you needed the validation. If it is for submission to OLC and
you need the validation you can try submitting the flight and then
contacting OLC support, they are aware of this exact issue and in the
past have manually approved some flights where this has occurred.

Periodically clearing the log memory (which will erase all your
traces, so make sure they are all downloaded first) should avoid you
seeing this problem. If you have a SeeYou Mobile PDA connected to the
C302 I've documented an easy way to do this at
http://www.darrylramm.com/2008/09/15/cambridge-302-vario-bug-clearing-log-memory-with-seeyou-mobile,
even if you don't have a SeeYou Mobile PDA connected look at the notes
there.

Sending the unit to Cambridge may well "fix" the problem only becasue
they clear the log memory for you. If you don't clear it yourself
periodically afterwards I expect the problem will come back. If you
need you vario now I would just clear the memory as described on my
blog post. Cambridge is also testing out different flash memory chips
that may reduce or solve this problem. I have the new chip in my C302
but it will take a long time for me to be comfortable this solves the
problem (ask me this time next year - and I've stopped clearing my log
memory, and am running at 1 Hz log rate to try to induce the problem
if it is there). If you send your unit to Cambridge you should talk to
them to see if it makes sense for them to install the new flash chip.

And Ray if you have been sending the vario to Cambridge multiple times
for this security fail problem, especially if it's happening every
year or so, it looks like you've been wasting your time -- but maybe
you've been helping provide useful information to Cambridge :-).
Personally I'd just make a habit of erasing log memory, by all
accounts it's an effective work-around. I've experienced this security
fail twice on two different loggers and clearing the log memory has
fixed, and kept at bay, the problem.

And preempting some confusion here... this is not related to other
problems with flight traces from Cambridge 20/25 GPS etc., the
workflow to download and validate traces from those devices etc. This
problem is inside the Cambridge 302.


Darryl

On Dec 7, 3:37*pm, " > wrote:
> And now, OLC won't accept my log from my CAI M-25 due to "format"
> issues and request I email it to the help desk. Hmmmmm
> I have since discover that the 302 memory battery may need replacing
> by Cambridge and only Cambridge ( I have a special place for that
> perfect 302 mailing box, I'm ahead of you girl).
> Lets shift this topic over to M-25 format issues, any help on this
> one?
> (I need to turn on the AC, its hot down here)
> R

The Cambridge 302 does not have a memory battery. It uses flash for
non-volatile memory.

Just submit your "security fail" flight from your Cambridge 302 and
contact OLC about the problem.

Darryl

Oh, boy.....this is getting tough.....I was not even aware one could
erase the logs. Ray, do yours and when you got it figured out, call me
and talk me through it. How you guys figure all this stuff out is out
there with Eisteinism and wormholes. Quarks and anti-matter.
R

On Dec 7, 4:05*pm, " > wrote:
> Oh, boy.....this is getting tough.....I was not even aware one could
> erase the logs. Ray, do yours and when you got it figured out, call me
> and talk me through it. How you guys figure all this stuff out is out
> there with Eisteinism and wormholes. Quarks and anti-matter.
> R

Paul Remde has a procedure for clearing the memory on his website.

http://www.cumulus-soaring.com/newsletter/newsletter-2007-11.htm#LETTER.BLOCK15

I think that will get you there.

Darryl Ramm wrote:

> Oh well you have not been periodically clearing the log memory on your
> Cambridge 302 have you?

Gary Kammerer, while still at Cambridge, told me that this was no longer
necessary with the latest firmware.

Tony v.

On Dec 7, 4:28*pm, TonyV > wrote:
> Darryl Ramm wrote:
> > Oh well you have not been periodically clearing the log memory on your
> > Cambridge 302 have you?
>
> Gary Kammerer, while still at Cambridge, told me that this was no longer
> necessary with the latest firmware.
>
> Tony v.

I don't believe that is true (but would be very happy to be
corrected). I think they've been trying lots of things. At one point
it was thought to the be the fault of the download utility, then the
firmware, ... and so the story goes on. My latest 302 failed and I
believe it was running at the latest firmware rev. Cambridge is still
working on this AFAIK, and the flash memory is the current suspect. At
least as the last time I talked to them (a month ago). I'd be clearing
the log memory....

Darryl

On Dec 7, 5:34*pm, Darryl Ramm > wrote:

>Cambridge is still working on this AFAIK

Who would that be? I thought everyone at Cambridge involved with
software and hardware development had moved on. I hope that'd not
true but I know that most of the people I have ever had contact with
are gone.


I have never erased my 302 and it has recorded well over 500 hours at
2 second interval. I have experienced the security fail problem I
think twice. It's interesting that a security fail on one flight will
not usually give a security fail on the next or subsequent flights.
Sending it back is probably a waste of money unless you need a
calibration. If the log memory was full for the one with security
fail it was still full for the subsequent flights.

Since Cambridge had a date/time math error in the utility code I
wonder if there is a date/time problem in the 302. Anyone willing to
post the start/end dates/times of any 302 logs with security fail?

Andy

Check on the test page (cycle through on button press until you get the
sensor readings, turn the knob until you see either 'Good Seal' or 'Bad
Seal' . Sometimes even with good seal there is a download verification
fail, repeating the download can give a good security.

Make sure you are using the most recent utility; older versions often give
intermittent results.

At 13:40 08 December 2008, Andy wrote:
>On Dec 7, 5:34=A0pm, Darryl Ramm wrote:
>
>>Cambridge is still working on this AFAIK
>
>Who would that be? I thought everyone at Cambridge involved with
>software and hardware development had moved on. I hope that'd not
>true but I know that most of the people I have ever had contact with
>are gone.
>
>
>I have never erased my 302 and it has recorded well over 500 hours at
>2 second interval. I have experienced the security fail problem I
>think twice. It's interesting that a security fail on one flight will
>not usually give a security fail on the next or subsequent flights.
>Sending it back is probably a waste of money unless you need a
>calibration. If the log memory was full for the one with security
>fail it was still full for the subsequent flights.
>
>Since Cambridge had a date/time math error in the utility code I
>wonder if there is a date/time problem in the 302. Anyone willing to
>post the start/end dates/times of any 302 logs with security fail?
>
>Andy
>

Peter Purdie wrote:
> Check on the test page (cycle through on button press until you get the
> sensor readings, turn the knob until you see either 'Good Seal' or 'Bad
> Seal' . Sometimes even with good seal there is a download verification
> fail, repeating the download can give a good security.
>
> Make sure you are using the most recent utility; older versions often give
> intermittent results.
>
> At 13:40 08 December 2008, Andy wrote:
>> On Dec 7, 5:34=A0pm, Darryl Ramm wrote:
>>
>>> Cambridge is still working on this AFAIK
>> Who would that be? I thought everyone at Cambridge involved with
>> software and hardware development had moved on. I hope that'd not
>> true but I know that most of the people I have ever had contact with
>> are gone.
>>
>>
>> I have never erased my 302 and it has recorded well over 500 hours at
>> 2 second interval. I have experienced the security fail problem I
>> think twice. It's interesting that a security fail on one flight will
>> not usually give a security fail on the next or subsequent flights.
>> Sending it back is probably a waste of money unless you need a
>> calibration. If the log memory was full for the one with security
>> fail it was still full for the subsequent flights.
>>
>> Since Cambridge had a date/time math error in the utility code I
>> wonder if there is a date/time problem in the 302. Anyone willing to
>> post the start/end dates/times of any 302 logs with security fail?
>>
>> Andy
>>

Take a look at the Cambridge web site under What's New,
http://www.cambridge-aero.com/whatsnew.htm.
They mention a fix for "A more robust flash memory for the 302, designed
to minimize a rare 'security fail' bug". I get the security failed once
in a while when the recording buffer wraps. Clearing the memory as
mentioned in earlier posts works also.

David Laitinen

On Dec 8, 8:26*am, David Laitinen > wrote:

> They mention a fix for "A more robust flash memory for the 302, designed
> to minimize a rare 'security fail' bug".

I wonder if they really found the root cause or if this a shotgun
fix. Has anyone with the flash update seen the problem?

> I get the security failed once in a while when the recording buffer wraps..

What is the indication that the buffer has wrapped and how are you
associating it with the security fail?

Andy

My 302 should be returned from Cambridge today. I had cleared the
memory before sending and still had the security fail problem.
WHen I spoke with the Tech at Cambridge, he told me my battery
showed 3.9 v and spec is 4 and that was likely causing the problem.

Bob

Darryl Ramm wrote:
> On Dec 7, 4:28 pm, TonyV > wrote:
>> Darryl Ramm wrote:
>>> Oh well you have not been periodically clearing the log memory on your
>>> Cambridge 302 have you?
>> Gary Kammerer, while still at Cambridge, told me that this was no longer
>> necessary with the latest firmware.
>>
>> Tony v.
>
> I don't believe that is true (but would be very happy to be
> corrected). I think they've been trying lots of things. At one point
> it was thought to the be the fault of the download utility, then the
> firmware, ... and so the story goes on. My latest 302 failed and I
> believe it was running at the latest firmware rev. Cambridge is still
> working on this AFAIK, and the flash memory is the current suspect. At
> least as the last time I talked to them (a month ago). I'd be clearing
> the log memory....
>
> Darryl

I regret that displays a woeful lack of knowledge of the only tech at CAI.
The volatile memory that loses the security when the case is opened will
happily retain its data well below 3.0V.

At 18:22 08 December 2008, Bob Backer wrote:
>My 302 should be returned from Cambridge today. I had cleared the
>memory before sending and still had the security fail problem.
>WHen I spoke with the Tech at Cambridge, he told me my battery
>showed 3.9 v and spec is 4 and that was likely causing the problem.
>
>Bob
>
>Darryl Ramm wrote:
>> On Dec 7, 4:28 pm, TonyV wrote:
>>> Darryl Ramm wrote:
>>>> Oh well you have not been periodically clearing the log memory on
your
>>>> Cambridge 302 have you?
>>> Gary Kammerer, while still at Cambridge, told me that this was no
>longer
>>> necessary with the latest firmware.
>>>
>>> Tony v.
>>
>> I don't believe that is true (but would be very happy to be
>> corrected). I think they've been trying lots of things. At one point
>> it was thought to the be the fault of the download utility, then the
>> firmware, ... and so the story goes on. My latest 302 failed and I
>> believe it was running at the latest firmware rev. Cambridge is still
>> working on this AFAIK, and the flash memory is the current suspect. At
>> least as the last time I talked to them (a month ago). I'd be
clearing
>> the log memory....
>>
>> Darryl
>

I regret that displays a woeful lack of knowledge of the only tech at CAI.
The volatile memory that loses the security when the case is opened will
happily retain its data well below 3.0V.

At 18:22 08 December 2008, Bob Backer wrote:
>My 302 should be returned from Cambridge today. I had cleared the
>memory before sending and still had the security fail problem.
>WHen I spoke with the Tech at Cambridge, he told me my battery
>showed 3.9 v and spec is 4 and that was likely causing the problem.
>
>Bob
>
>Darryl Ramm wrote:
>> On Dec 7, 4:28 pm, TonyV wrote:
>>> Darryl Ramm wrote:
>>>> Oh well you have not been periodically clearing the log memory on
your
>>>> Cambridge 302 have you?
>>> Gary Kammerer, while still at Cambridge, told me that this was no
>longer
>>> necessary with the latest firmware.
>>>
>>> Tony v.
>>
>> I don't believe that is true (but would be very happy to be
>> corrected). I think they've been trying lots of things. At one point
>> it was thought to the be the fault of the download utility, then the
>> firmware, ... and so the story goes on. My latest 302 failed and I
>> believe it was running at the latest firmware rev. Cambridge is still
>> working on this AFAIK, and the flash memory is the current suspect. At
>> least as the last time I talked to them (a month ago). I'd be
clearing
>> the log memory....
>>
>> Darryl
>

I regret that displays a woeful lack of knowledge of the only tech at CAI.
The volatile memory that loses the security when the case is opened will
happily retain its data well below 3.0V.

At 18:22 08 December 2008, Bob Backer wrote:
>My 302 should be returned from Cambridge today. I had cleared the
>memory before sending and still had the security fail problem.
>WHen I spoke with the Tech at Cambridge, he told me my battery
>showed 3.9 v and spec is 4 and that was likely causing the problem.
>
>Bob
>
>Darryl Ramm wrote:
>> On Dec 7, 4:28 pm, TonyV wrote:
>>> Darryl Ramm wrote:
>>>> Oh well you have not been periodically clearing the log memory on
your
>>>> Cambridge 302 have you?
>>> Gary Kammerer, while still at Cambridge, told me that this was no
>longer
>>> necessary with the latest firmware.
>>>
>>> Tony v.
>>
>> I don't believe that is true (but would be very happy to be
>> corrected). I think they've been trying lots of things. At one point
>> it was thought to the be the fault of the download utility, then the
>> firmware, ... and so the story goes on. My latest 302 failed and I
>> believe it was running at the latest firmware rev. Cambridge is still
>> working on this AFAIK, and the flash memory is the current suspect. At
>> least as the last time I talked to them (a month ago). I'd be
clearing
>> the log memory....
>>
>> Darryl
>

I regret that displays a woeful lack of knowledge of the only tech at CAI.
The volatile memory that loses the security when the case is opened will
happily retain its data well below 3.0V.

At 18:22 08 December 2008, Bob Backer wrote:
>My 302 should be returned from Cambridge today. I had cleared the
>memory before sending and still had the security fail problem.
>WHen I spoke with the Tech at Cambridge, he told me my battery
>showed 3.9 v and spec is 4 and that was likely causing the problem.
>
>Bob
>
>Darryl Ramm wrote:
>> On Dec 7, 4:28 pm, TonyV wrote:
>>> Darryl Ramm wrote:
>>>> Oh well you have not been periodically clearing the log memory on
your
>>>> Cambridge 302 have you?
>>> Gary Kammerer, while still at Cambridge, told me that this was no
>longer
>>> necessary with the latest firmware.
>>>
>>> Tony v.
>>
>> I don't believe that is true (but would be very happy to be
>> corrected). I think they've been trying lots of things. At one point
>> it was thought to the be the fault of the download utility, then the
>> firmware, ... and so the story goes on. My latest 302 failed and I
>> believe it was running at the latest firmware rev. Cambridge is still
>> working on this AFAIK, and the flash memory is the current suspect. At
>> least as the last time I talked to them (a month ago). I'd be
clearing
>> the log memory....
>>
>> Darryl
>

I regret that displays a woeful lack of knowledge of the only tech at CAI.
The volatile memory that loses the security when the case is opened will
happily retain its data well below 3.0V.

At 18:22 08 December 2008, Bob Backer wrote:
>My 302 should be returned from Cambridge today. I had cleared the
>memory before sending and still had the security fail problem.
>WHen I spoke with the Tech at Cambridge, he told me my battery
>showed 3.9 v and spec is 4 and that was likely causing the problem.
>
>Bob
>
>Darryl Ramm wrote:
>> On Dec 7, 4:28 pm, TonyV wrote:
>>> Darryl Ramm wrote:
>>>> Oh well you have not been periodically clearing the log memory on
your
>>>> Cambridge 302 have you?
>>> Gary Kammerer, while still at Cambridge, told me that this was no
>longer
>>> necessary with the latest firmware.
>>>
>>> Tony v.
>>
>> I don't believe that is true (but would be very happy to be
>> corrected). I think they've been trying lots of things. At one point
>> it was thought to the be the fault of the download utility, then the
>> firmware, ... and so the story goes on. My latest 302 failed and I
>> believe it was running at the latest firmware rev. Cambridge is still
>> working on this AFAIK, and the flash memory is the current suspect. At
>> least as the last time I talked to them (a month ago). I'd be
clearing
>> the log memory....
>>
>> Darryl
>

On Dec 8, 5:40*am, Andy > wrote:
> On Dec 7, 5:34*pm, Darryl Ramm > wrote:
>
> >Cambridge is still working on this AFAIK
>
> Who would that be? *I thought everyone at Cambridge involved with
> software and hardware development had moved on. * I hope that'd not
> true but I know that most of the people I have ever had contact with
> are gone.
>
> I have never erased my 302 and it has recorded well over 500 hours at
> 2 second interval. *I have experienced the security fail problem I
> think twice. *It's interesting that a security fail on one flight will
> not usually give a security fail on the next or subsequent flights.
> Sending it back is probably a waste of money unless you need a
> calibration. * If the log memory was full for the one with security
> fail it was still full for the subsequent flights.
>
> Since Cambridge had a date/time math error in the utility code I
> wonder if there is a date/time problem in the 302. *Anyone willing to
> post the start/end dates/times of any 302 logs with security fail?
>
> Andy

There are different symptoms and probably different causes. The
security fails I have experienced do not go away if you retry or use
different download tools and all subsequent flight will fail. As I
noted on my blog but should have said inline, if you see a bad seal
message on the device that is a different problem - a real bad seal
that needs to be fixed.

There was no obvious date/time problem on failed logs. An example
flight with such a security fail is here
http://www.onlinecontest.org/olc-2.0/gliding/flightinfo.html?flightId=482183925

So again if I saw a fail like this I would definitly take the
precaution of erasing the log memory before the next flight.

Darryl

On Dec 8, 12:16*pm, Darryl Ramm > wrote:
> There are different symptoms and probably different causes.

I didn't have a bad seal indication. The seal was good, the security
was bad, next log had good security. I only realized the next log
had good security after I sent it back to be fixed. Hence the
conclusion that sending it back was a waste of money.

Andy

On Dec 8, 2:26*pm, Andy > wrote:
> On Dec 8, 12:16*pm, Darryl Ramm > wrote:
>
> > There are different symptoms and probably different causes.
>
> I didn't have a bad seal indication. *The seal was good, the security
> was bad, next log had good security. * I only realized the next log
> had good security after I sent it back to be fixed. *Hence the
> conclusion that sending it back was a waste of money.
>
> Andy

I wonder if all units are vulnerable? Mine has several hundred hours
on it, memory was full when I bought it (Spring 08) and I've
subsequently put 80 odd flight hours on it with no failures. Sometime
this Fall I had the thought to go back and check every single log in
the recorder to see if there were any failures that I might have
missed (20 minute sled ride, aero-retrieve, etc.) and there are none.
So it does appear possible, at least occasionally, to completely fill
the 302 memory without inducing the security failure.

-Evan Ludeman / T8

On Dec 8, 11:48*am, wrote:
> On Dec 8, 2:26*pm, Andy > wrote:
>
> > On Dec 8, 12:16*pm, Darryl Ramm > wrote:
>
> > > There are different symptoms and probably different causes.
>
> > I didn't have a bad seal indication. *The seal was good, the security
> > was bad, next log had good security. * I only realized the next log
> > had good security after I sent it back to be fixed. *Hence the
> > conclusion that sending it back was a waste of money.
>
> > Andy
>
> I wonder if all units are vulnerable? *Mine has several hundred hours
> on it, memory was full when I bought it (Spring 08) and I've
> subsequently put 80 odd flight hours on it with no failures. *Sometime
> this Fall I had the thought to go back and check every single log in
> the recorder to see if there were any failures that I might have
> missed (20 minute sled ride, aero-retrieve, etc.) and there are none.
> So it does appear possible, at least occasionally, to completely fill
> the 302 memory without inducing the security failure.
>
> -Evan Ludeman / T8

The problem is isolated and clearly many C302 can wrap log memory
(many times) with no problems, soem other 302s may never get to wrap
they log memory if they have slow log rates, don't fly much and/or are
are calibrated periodically (when log mmory will be cleared). All this
assumes that the folk law on wrapping the log memory is correct.
Maybe it's certain units that are more problematic, maybe it's related
to some pseudo random things like what memory address things happen to
start or end at and so maybe we are all playing Russian roulette. I
hope Cambridge have a handle on this now with the FLASH memory chip
change. Like I said I've stopped clearing memory and am running at 1Hz
log rate and will see.

So while irritating for us who experience this, it is nice to get such
quick turn around from the US based factory on service stuff.


Darryl

As the originator of this thread, today I did not get "Security Fail "
after my flight. Jeff, the main man at CAI stated this morning that
subsequential flights with S Fail problems most likely means a battery
issue. In review, I believe my problem yesterday may have been being
to quick to transfer flight info. after aircraft came to a stop. I
hope, anyway. This was the first burp on a unit with over 900 hours on
it. Lets see what happens tomorrow.
R

On Dec 8, 6:23*pm, " > wrote:
> In review, I believe my problem yesterday may have been being
> to quick to transfer flight info. after aircraft came to a stop.

That's interesting. Did Cambridge suggest there was some minimum time
that should elapse between landing and download?

Andy

Sorry it took so long to get back. I thought I read in the manual to
allow a few minutes after stopping for the unit to settle and log "on
ground". I waited only seconds after stopping to transfer before
climbing out of the cockpit. I'm not sure if there is a connection
with my S Fail indication. Looking at the above postings proves to me
I'm out on the fringe of understanding any of this.
R

On Dec 9, 4:20*pm, Tim Newport-Peace ]> wrote:

> I am wondering if this problem is due to trying to download while still
> recording.

Me too. I would be a **** poor design if the utility was allowed to
access the log file before it been properly closed but it wouldn't
surprise me. I suppose a useful test would be to try a download while
still in motion.

Something to try on a winter local flight perhaps.

Andy

> On Dec 9, 4:20*pm, Tim Newport-Peace ]> wrote:
>
> > I am wondering if this problem is due to trying to download while still
> > recording
>

My 302A CFR has been giving me a security fail notice in the Cambidge
Utility progamme after every download for at least 2 seasons. Often I
have downloaded the flight log when de-rigging long after landing so
in my case at least I am sure that downloading while still recording
is not the cause of the problem.

I have cleared the memory on 2 separate occasions and that made no
difference either.

John Galloway

Hooked up to a PDA or PC with a terminal program. typ VER <return>.

The 302A will give a text message, concluding (if there is a bad
electronic seal) with 'Security Fail'.

If so, in UK send it to me at RD Aviation or Dickie Feakes where it can be
resealed (after checking the memory battery voltage and replacing if
necessary).

Pete Purdie

At 19:48 11 December 2008, wrote:
>> On Dec 9, 4:20=A0pm, Tim Newport-Peace wrote:
>>
>> > I am wondering if this problem is due to trying to download while
>still
>> > recording
>>
>
>My 302A CFR has been giving me a security fail notice in the Cambidge
>Utility progamme after every download for at least 2 seasons. Often I
>have downloaded the flight log when de-rigging long after landing so
>in my case at least I am sure that downloading while still recording
>is not the cause of the problem.
>
>I have cleared the memory on 2 separate occasions and that made no
>difference either.
>
>John Galloway
>

On Dec 11, 3:45*pm, Peter Purdie > wrote:
> Hooked up to a PDA or PC with a terminal program. typ VER <return>.
>
> The 302A will give a text message, concluding (if there is a bad
> electronic seal) with 'Security Fail'.
>
> If so, in UK send it to me at RD Aviation or Dickie Feakes where it can be
> resealed (after checking the memory battery voltage and replacing if
> necessary).

The security fail report does not indicate that the seal is bad.
Please assist Cambridge with fixing the design problem rather than
using it to solicit business!

Andy

On Dec 8, 6:23*pm, " > wrote:
> I believe my problem yesterday may have been being
> to quick to transfer flight info. after aircraft came to a stop. I
> hope, anyway. This was the first burp on a unit with over 900 hours on
> it. Lets see what happens tomorrow.

I often start a transfer before even getting out of the cockpit.

In over 800 hours of use with 2 second logging interval, I've only had
a single security failure. I have no clue how often the memory has
wrapped, though.

-Tom

On Dec 12, 4:06*am, Tim Newport-Peace ]> wrote:

> Andy, I think you are being a little harsh.

Peter, I appologize. When I read my response later I realized it was
inappropriate.

I just get a bit wound up when people associate the security fail
problem with the hardware seal of the unit. Resealing the units does
not fix the problem. The root cause remains and the problem will
happen again.

Just to be sure there is no ambiguity here - 302 flight logs can, and
sometimes do, report security failure when the instrument indicates
that the hardware seal is good.

Andy

Thank you Tim for pointing out the obvious. I was suggesting that it is
necessary on a 302A (which has no on-screen display) it is useful to check
that the unit is sealed; if it is a bad seal it can be fixed. The security
fail message gives no indication of the cause of verification fail. The
charge from RD is zero profit in my case, regarded as part of product
support. I don't think Dickie makes a fortune either.

I would be delighted if CAI could sort this, and several other issues.
Unfortunately there is no development or debugging capability at CAI, and
I can do nothing about that.

For what it's worth, I firmly believe that the memory wrap is a complete
red-herring; units that downloaded fligths with failed verification later
downloaded the same flight with different utility software OK. I suspect
from investigation, based on limited information available to me that the
problem units use a different flash memory from the original design due to
the original memory going out of production. This may give rise to timing
issues.


At 01:51 12 December 2008, Andy wrote:
>On Dec 11, 3:45=A0pm, Peter Purdie wrote:
>> Hooked up to a PDA or PC with a terminal program. typ VER .
>>
>> The 302A will give a text message, concluding (if there is a bad
>> electronic seal) with 'Security Fail'.
>>
>> If so, in UK send it to me at RD Aviation or Dickie Feakes where it
can
>b=
>e
>> resealed (after checking the memory battery voltage and replacing if
>> necessary).
>
>The security fail report does not indicate that the seal is bad.
>Please assist Cambridge with fixing the design problem rather than
>using it to solicit business!
>
>Andy
>

Question, it seems you don't know before the flight if you will get a
security fail. If after a flight the seal is good but you get a security
fail would this invalidate a badge flight?


At 20:00 12 December 2008, Peter Purdie wrote:
>Thank you Tim for pointing out the obvious. I was suggesting that it is
>necessary on a 302A (which has no on-screen display) it is useful to
check
>that the unit is sealed; if it is a bad seal it can be fixed. The
security
>fail message gives no indication of the cause of verification fail. The
>charge from RD is zero profit in my case, regarded as part of product
>support. I don't think Dickie makes a fortune either.
>
>I would be delighted if CAI could sort this, and several other issues.
>Unfortunately there is no development or debugging capability at CAI,
and
>I can do nothing about that.
>
>For what it's worth, I firmly believe that the memory wrap is a
complete
>red-herring; units that downloaded fligths with failed verification
later
>downloaded the same flight with different utility software OK. I
suspect
>from investigation, based on limited information available to me that
the
>problem units use a different flash memory from the original design due
to
>the original memory going out of production. This may give rise to
timing
>issues.
>
>
>At 01:51 12 December 2008, Andy wrote:
>>On Dec 11, 3:45=A0pm, Peter Purdie wrote:
>>> Hooked up to a PDA or PC with a terminal program. typ VER .
>>>
>>> The 302A will give a text message, concluding (if there is a bad
>>> electronic seal) with 'Security Fail'.
>>>
>>> If so, in UK send it to me at RD Aviation or Dickie Feakes where it
>can
>>b=
>>e
>>> resealed (after checking the memory battery voltage and replacing if
>>> necessary).
>>
>>The security fail report does not indicate that the seal is bad.
>>Please assist Cambridge with fixing the design problem rather than
>>using it to solicit business!
>>
>>Andy
>>
>

Question, it seems you don't know before a flight if you will get a
security fail. If after a flight the seal is good but you get the security
fail would it invalidate a badge flight?



At 20:00 12 December 2008, Peter Purdie wrote:
>Thank you Tim for pointing out the obvious. I was suggesting that it is
>necessary on a 302A (which has no on-screen display) it is useful to
check
>that the unit is sealed; if it is a bad seal it can be fixed. The
security
>fail message gives no indication of the cause of verification fail. The
>charge from RD is zero profit in my case, regarded as part of product
>support. I don't think Dickie makes a fortune either.
>
>I would be delighted if CAI could sort this, and several other issues.
>Unfortunately there is no development or debugging capability at CAI,
and
>I can do nothing about that.
>
>For what it's worth, I firmly believe that the memory wrap is a
complete
>red-herring; units that downloaded fligths with failed verification
later
>downloaded the same flight with different utility software OK. I
suspect
>from investigation, based on limited information available to me that
the
>problem units use a different flash memory from the original design due
to
>the original memory going out of production. This may give rise to
timing
>issues.
>
>
>At 01:51 12 December 2008, Andy wrote:
>>On Dec 11, 3:45=A0pm, Peter Purdie wrote:
>>> Hooked up to a PDA or PC with a terminal program. typ VER .
>>>
>>> The 302A will give a text message, concluding (if there is a bad
>>> electronic seal) with 'Security Fail'.
>>>
>>> If so, in UK send it to me at RD Aviation or Dickie Feakes where it
>can
>>b=
>>e
>>> resealed (after checking the memory battery voltage and replacing if
>>> necessary).
>>
>>The security fail report does not indicate that the seal is bad.
>>Please assist Cambridge with fixing the design problem rather than
>>using it to solicit business!
>>
>>Andy
>>
>

At 20:00 12 December 2008, Peter Purdie wrote:
>Thank you Tim for pointing out the obvious. I was suggesting that it is
>necessary on a 302A (which has no on-screen display) it is useful to
check
>that the unit is sealed; if it is a bad seal it can be fixed. The
security
>fail message gives no indication of the cause of verification fail. The
>charge from RD is zero profit in my case, regarded as part of product
>support. I don't think Dickie makes a fortune either.
>
>I would be delighted if CAI could sort this, and several other issues.
>Unfortunately there is no development or debugging capability at CAI,
and
>I can do nothing about that.
>
>For what it's worth, I firmly believe that the memory wrap is a
complete
>red-herring; units that downloaded fligths with failed verification
later
>downloaded the same flight with different utility software OK. I
suspect
>from investigation, based on limited information available to me that
the
>problem units use a different flash memory from the original design due
to
>the original memory going out of production. This may give rise to
timing
>issues.
>
>
>At 01:51 12 December 2008, Andy wrote:
>>On Dec 11, 3:45=A0pm, Peter Purdie wrote:
>>> Hooked up to a PDA or PC with a terminal program. typ VER .
>>>
>>> The 302A will give a text message, concluding (if there is a bad
>>> electronic seal) with 'Security Fail'.
>>>
>>> If so, in UK send it to me at RD Aviation or Dickie Feakes where it
>can
>>b=
>>e
>>> resealed (after checking the memory battery voltage and replacing if
>>> necessary).
>>
>>The security fail report does not indicate that the seal is bad.
>>Please assist Cambridge with fixing the design problem rather than
>>using it to solicit business!
>>
>>Andy
>>
>

On Dec 12, 12:00*pm, Peter Purdie > wrote:
> Thank you Tim for pointing out the obvious. *I was suggesting that it is
> necessary on a 302A (which has no on-screen display) it is useful to check
> that the unit is sealed; if it is a bad seal it can be fixed. The security
> fail message gives no indication of the cause of verification fail. The
> charge from RD is zero profit in my case, regarded as part of product
> support. I don't think Dickie makes a fortune either.
>
> I would be delighted if CAI could sort this, and several other issues.
> Unfortunately there is no development or debugging capability at CAI, and
> I can do nothing about that.
>
> For what it's worth, I firmly believe that the memory wrap is a complete
> red-herring; units that downloaded fligths with failed verification later
> downloaded the same flight with different utility software OK. *I suspect
> from investigation, based on limited information available to me that the
> problem units use a different flash memory from the original design due to
> the original memory going out of production. *This may give rise to timing
> issues. *
>
> At 01:51 12 December 2008, Andy wrote:
>
> >On Dec 11, 3:45=A0pm, Peter Purdie *wrote:
> >> Hooked up to a PDA or PC with a terminal program. typ VER .
>
> >> The 302A will give a text message, concluding (if there is a bad
> >> electronic seal) with 'Security Fail'.
>
> >> If so, in UK send it to me at RD Aviation or Dickie Feakes where it
> can
> >b=
> >e
> >> resealed (after checking the memory battery voltage and replacing if
> >> necessary).
>
> >The security fail report does not indicate that the seal is bad.
> >Please assist Cambridge with fixing the design problem rather than
> >using it to solicit business!
>
> >Andy
>
>

Some units may later download flights OK if you try different
utilities, and some units some may not. I've had two different C302s
that once they start getting security fails (with good seals) that no
utility (latest Cambridge utility on PDA or PC or DATA-CAM2, or
Naviter Connect Me) would get security fails on subsequent flights (I
tried 2 or 3 in each case), until a CLEAR LOG was done.

I think the real answer is that nodody knows for sure what is
happening and all we can do is wait and see if the latest flash memory
chip change improves things. But until then, based on my experience, I
would suggest clearing the log before any critical flight, in the
(unproven) hope that this may decrease the likelihood of this
occurring (it is however scientifically proven that this will keep
elephants away).


Darryl